1. Field of the Invention
The present invention relates generally to a system and method which allows subsystem modules containing module specific firmware in read only memories (ROMs) to be connected in different configurations. More particularly, it relates to such a system and method which will allow the firmware to be copied to system memory locations that will vary depending on system configuration for execution.
2. Description of the Prior Art
Computer systems often are composed of multiple modules that may be connected in different configurations. This multiplicity of configurations allows the systems to be tailored for the problem at hand. In many system designs, module specific firmware is stored on each module in ROMs. This firmware is used for a variety of purposes, with diagnostic software and bootstrap software being most common.
ROM based firmware is normally stored in a form that is either executed directly or first copied to a fixed location in memory and executed there. In system architectures such as the MIPS R2000/R3000, the address where this code must be executed is fixed when it is placed in ROM. Since systems can be subsequently configured with an arbitrary collection of modules, it is very difficult to insure that the code from different modules does not have overlapping address ranges assigned to it. If the address ranges overlap, the system will not work. Nevertheless, simultaneous access to the code of multiple options is necessary to perform some firmware tasks. The problem is to provide a means to load and execute code stored in multiple option module ROMs. This problem is especially severe if a user is able to reconfigure his or her system with varying option modules according to needs after initial installation of the system.
It might be possible to store such code in absolute format, but copy it into random access memory (RAM) and inspect the copied code to determine which memory addresses referred to in the code need to be changed (relocated) to avoid overlapping address ranges, based solely on inspection of the code itself. However, any simple inspect and relocate algorithm tends to make mistakes. Therefore, unless the code is written in assembly language, this approach cannot be made to work in practice. Coding in assembly language is labor intensive and time consuming. The ability to use a higher level language, such as C, is desired.
Another known approach is to store code in a higher level language, such as FORTH, in ROM and use a FORTH interpreter on a base module of the system to interpret the code. This interpretive approach avoids the problem by storing the FORTH code in character format, and it need not contain any address specific information. However, FORTH and FORTH-like languages are poor languages to use for large software projects. For large projects, FORTH is difficult to understand and maintain.
Some computer systems, such as Digital Equipment Corporation's VAAX systems, when supported by the appropriate software tools, can generate position independent code. This is code that can be executed directly by the computer, but which contains little or no absolute address information. With such systems, the above problems can be avoided. However, such software tools are not available for all systems, especially newer systems.